In a multimedia streaming service, there are three participants involved in the streaming service, a streaming server, a streaming client and a transmission medium. The transmission medium is a path that consists of a chain of point-to-point line components, where the overall behavior is usually constrained by a bottleneck link in the path. In a mobile network, the bottleneck link is usually on the air interface, which is the last hop to the terminal in a downlink streaming scenario. The streaming server adjusts the transmission bitrate to the varying available bandwidth on the bottleneck link. While doing so, the streaming server also controls the streaming client's receiver buffer fullness level so as to avoid buffer underflow (i.e. playout interruption) or overflow (i.e. packet drops) at the client. In 3GPP TS 26.234 V5.0.0 (2002-03) “Transparent end-to-end packet switched streaming service (PSS); Protocols and codecs” (Release 5), the streaming client at the beginning of the streaming session buffers a negotiated pre-determined amount of data before the actual playout starts (initial receiver buffering delay). Knowing the initial receiver buffering delay the server thereafter estimates the receiver buffer fullness level by assuming that the client follows exactly the sampling timestamps of the media for playout. The server does not know whether the client behaves as assumed. For example, it is possible that the client's clock may drift relative to the server's clock. Also, the client's playout rate may be slowed down or the client may perform extra buffering.
System clock drift—the accepted standard of accuracy in modern electronic systems is ±1 minute per month at 25° C. and ±40 minutes per year at 60° C. Uncompensated timing crystals can cause system clocks to gain or lose as much as 100 minutes per year in operation over the industrial temperature range. If we assume the accuracy of the server's clock and the client's clock is ±40 minutes per year and the server and the client's clocks are drifting in opposite directions, the relative drift is 0.5479 seconds per hour. If the accuracy is ±100 minutes per year and the server and the client's clocks are drifting in opposite directions, the relative drift is 1.3699 seconds per hour.
Client system slow down—if many applications are running at the same time, the client operation system could be slowed down, causing slower playout.
Extra buffering—it is possible that the client initially buffers a larger amount than the negotiated value without the acknowledgment of the server. This results in extra buffering. Also, the client may perform rebuffering (i.e. further delaying the playout) if the receiver buffer underflows due to exceptionally long packet delays (e.g. at a time of a mobile handover).
In the above-mentioned situations, the server's assumptions about the receiver buffer fullness level will be incorrect because the client does not play out at exactly the rate as the server assumes. Thus, when the server executes the rate adaptation operations relying on the assumed receiver buffer fullness level, underflow or overflow in the receiver buffer may occur.
In prior art PSS streaming system, there are no mechanisms to prevent the incorrect assumptions from happening and to eliminate the difference between the actual fullness level and the server assumed fullness level in the receiver buffer. Whenever a receiver buffer underflow or overflow happens due to incorrect assumptions, the streaming client has to handle such receiver buffer violation on its own (i.e. performing rebuffering or dropping packets). Alternatively, in a receiver buffer violation situations the client can request the streaming server to re-initialize the streaming session by sending a new RTSP (Real-time Streaming Protocol) PLAY request, re-initializing the streaming session and thereby re-establishing the server's correct assumptions about the receiver buffer fullness level.
Similar problem arises in prior-art remote live camera feed applications, where live video signals (e.g. special news and sport events) are streamed from multiple cameras (video sources) to a central television studio over an IP (Internet Protocol) connection. The live feed is forwarded from the central studio to one or more broadcast station for broadcast. When two or more video sources are combined for streaming, the streaming system must ensure that time synchronization is maintained among all the sources and the central studio. To that end, the central studio maintains a master sync generator or master clock (“house sync”), running for example at the U.S. standard frequency of 29.97 frames per second, to which the entire studio plant is synchronized. If the cameras are operating in a “free running” mode, their time base will drift relative to the studio's house sync and video frames will have to be dropped or duplicated during the broadcast in the effort to maintain real-timeness of the playout. According to IETF draft-harrision-avt-interlock-01.txt, “Timebase Interlock in Real-time Transport Protocol (RTP) Conferences”, C. Harrison, proposed draft, March 2001, it is possible to send via Real-time Control Protocol (RTCP) extension a “Timebase Management (TBM) buffer status message” from the central studio to the remote cameras to report the “amount of data remaining in buffer in kbytes” in the studio receiver buffer. As such, based on this buffer status message each of the cameras detects whether its clock drifts and adjusts its clock in order to synchronize the clock to the house sync. Alternatively, the central studio can send “TBM speed control messages” to ask specifically each of the cameras to adjust its clock, based on the clock drift estimated by the studio.